1
2
další
Ne.
JSON jsou pouze data a pokud uvedete komentář, budou to také data.
Můžete mít určený datový prvek s názvem „_comment“ (nebo něco), který by aplikace, které používají data JSON, měly být ignorovány.
Pravděpodobně byste měli mít lepší komentář v procesech, které generují / přijímají JSON, protože mají vědět, jaké údaje JSON budou předem, nebo alespoň jeho struktura.
Ale pokud jste se rozhodli:
{
"_comment": "text komentáře jde sem ...",
"glosář": {
"title": "ukázkový glosář",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup Language",
"Acronym": "SGML",
"Abbrev": "ISO 8879: 1986",
"GlossDef": {
"para": "Meta-značkovací jazyk, který se používá k vytváření značkovacích jazyků, jako je DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "označení"
}
}
}
}
}
|
Ne, komentáře ve tvaru //… nebo / *… * / nejsou v JSONu povoleny. Tato odpověď je založena na:
https://www.json.org
RFC 4627:
Typ média aplikace / json pro JavaScript Object Notation (JSON)
RFC 8259 Formát výměny dat JSON (JavaScript Object Notation) (nahrazuje RFC 4627, 7158, 7159)
|
Pokud chcete, zahrňte komentáře; před analýzou nebo přenosem je odstraňte pomocí minifikátoru.
Právě jsem vydal JSON.minify (), který odstraní komentáře a mezery z bloku JSON a učiní z něj platný JSON, který lze analyzovat. Můžete jej tedy použít jako:
JSON.parse (JSON.minify (my_str));
Když jsem to vydal, dostal jsem obrovský odpor lidí nesouhlasících dokonce s myšlenkou na to, tak jsem se rozhodl, že napíšu komplexní blogový příspěvek o tom, proč mají komentáře v JSONu smysl. Zahrnuje tento pozoruhodný komentář od tvůrce JSON:
Předpokládejme, že používáte JSON k uchování konfiguračních souborů, které byste chtěli anotovat. Pokračujte a vložte všechny komentáře, které se vám líbí. Poté jej předejte do JSMin, než jej předáte svému analyzátoru JSON. - Douglas Crockford, 2012
Doufejme, že je to užitečné pro ty, kteří nesouhlasí s tím, proč by JSON.minify () mohl být užitečný.
|
Komentáře byly z JSON odstraněny záměrně.
Odebral jsem komentáře z JSON, protože jsem viděl, že je lidé používají k provádění analýz směrnic, což je postup, který by zničil interoperabilitu. Vím, že nedostatek komentářů některé lidi mrzí, ale nemělo by.
Předpokládejme, že používáte JSON k uchování konfiguračních souborů, které byste chtěli anotovat. Pokračujte a vložte všechny komentáře, které se vám líbí. Poté jej předejte do JSMin, než jej předáte svému analyzátoru JSON.
Zdroj: Veřejné prohlášení Douglase Crockforda na G +
|
JSON nepodporuje komentáře. Rovněž nikdy nemělo být použito pro konfigurační soubory, kde by bylo zapotřebí komentářů.
Hjson je formát konfiguračního souboru pro člověka. Uvolněná syntaxe, méně chyb, více komentářů.
Knihovny JavaScript, Java, Python, PHP, Rust, Go, Ruby, C ++ a C # najdete na hjson.github.io.
|
Zřeknutí se odpovědnosti: VAŠE ZÁRUKA JE NEPLATNÁ
Jak již bylo uvedeno, tento hack využívá implementaci specifikace. Ne všechny analyzátory JSON tomuto druhu JSON porozumí. Zejména streamovací analyzátory se dusí.
Je to zajímavá kuriozita, ale opravdu byste ji neměli používat vůbec k ničemu. Níže je původní odpověď.
Našel jsem malý hack, který vám umožní umístit komentáře do souboru JSON, který nebude mít vliv na analýzu nebo jakýmkoli způsobem pozmění data, která jsou reprezentována.
Zdá se, že při deklaraci literálu objektu můžete zadat dvě hodnoty se stejným klíčem a poslední má přednost. Věřte tomu nebo ne, ukázalo se, že analyzátory JSON fungují stejně. Můžeme to tedy použít k vytvoření komentářů ve zdrojovém JSONu, které nebudou přítomny v reprezentaci analyzovaného objektu.
({a: 1, a: 2});
// => Objekt {a: 2}
Object.keys (JSON.parse ('{"a": 1, "a": 2}')). Length;
// => 1
Pokud použijeme tuto techniku, může váš soubor JSON s poznámkami vypadat takto:
{
"api_host": "Název hostitele vašeho serveru API. Můžete také určit port.",
"api_host": "hodorhodor.com",
"retry_interval": "Interval v sekundách mezi opakováním neúspěšných volání API",
"retry_interval": 10,
"auth_token": "Ověřovací token. Je k dispozici na hlavním panelu vývojáře v části„ Nastavení "",
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favourite_numbers": "Pole obsahující moje oblíbená čísla všech dob",
"oblíbené_čísla": [19, 13, 53]
}
Výše uvedený kód je platný JSON. Pokud jej analyzujete, dostanete takový objekt:
{
"api_host": "hodorhodor.com",
"retry_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"oblíbené_čísla": [19,13,53]
}
Což znamená, že po komentářích není žádná stopa a nebudou mít divné vedlejší účinky.
Šťastné hackování!
|
Zvažte použití YAML. Je to téměř nadmnožina JSON (prakticky veškerý platný JSON je platný YAML) a umožňuje komentáře.
|
Nemůžeš. Alespoň to je moje zkušenost z rychlého pohledu na json.org.
JSON má svou syntaxivizualizováno na této stránce. O komentářích není žádná poznámka.
|
Komentáře nejsou oficiálním standardem, ačkoli některé analyzátory podporují komentáře ve stylu C ++. Jeden, který používám, je JsonCpp. V příkladech je tento:
// Možnosti konfigurace
{
// Výchozí kódování textu
"encoding": "UTF-8",
// Pluginy jsou načteny při spuštění
"plug-iny": [
"krajta",
"c ++",
"rubín"
],
// Velikost odsazení záložky
"indent": {"length": 3, "use_space": true}
}
jsonlint to neověřuje. Komentáře jsou tedy rozšířením specifickým pro analyzátor a nejsou standardní.
Dalším analyzátorem je JSON5.
Alternativa k JSON TOML.
Další alternativou je jsonc.
Nejnovější verze nlohmann / json má volitelnou podporu pro ignorování komentářů k analýze.
|
Místo toho byste měli napsat schéma JSON. Schéma JSON je aktuálně navrhovanou specifikací internetového konceptu. Kromě dokumentace lze schéma použít také k ověření vašich dat JSON.
Příklad:
{
"description": "Osoba",
"type": "object",
"vlastnosti":
{
"název":
{
"type": "string"
},
"stáří":
{
"type": "integer",
"maximum": 125
}
}
}
Dokumentaci můžete poskytnout pomocí atributu description schema.
|
Pokud používáte Jackson jako analyzátor JSON, povolíte jej tak, aby umožňoval komentáře:
ObjectMapper mapper = nový ObjectMapper (). Configure (Feature.ALLOW_COMMENTS, true);
Pak můžete mít takové komentáře:
{
key: "value" // Komentář
}
Můžete také mít komentáře začínající na # nastavením:
mapper.configure (Feature.ALLOW_YAML_COMMENTS, true);
Obecně však (jak bylo odpovězeno dříve) specifikace neumožňuje komentáře.
|
Zde je to, co jsem našel v dokumentaci Google Firebase, která vám umožňuje vkládat komentáře do JSON:
{
"//": "Některé prohlížeče toto použijí k povolení nabízených oznámení.",
"//": "Je to stejné pro všechny projekty, toto není ID odesílatele vašeho projektu",
"gcm_sender_id": "1234567890"
}
|
NE. JSON dříve podporoval komentáře, ale byly zneužity a odstraněny ze standardu.
Od tvůrce JSON:
Odebral jsem komentáře z JSON, protože jsem viděl, že je lidé používají k provádění analýz směrnic, což je postup, který by zničil interoperabilitu. Vím, že nedostatek komentářů některé lidi mrzí, ale nemělo by. - Douglas Crockford, 2012
Oficiální stránka JSON je na JSON.org. JSON je definován jako standard ECMA International. K revizi standardů vždy existuje petiční proces. Je nepravděpodobné, že do standardu JSON budou přidány anotace z několika důvodů.
JSON by design is a easily reverse-engineered (human parsed) alternative to XML. Je to zjednodušeno dokonce do té míry, že anotace jsou zbytečné. Není to ani značkovací jazyk. Cílem je stabilita a interoperabilita.
Kdokoli, kdo rozumí vztahu „má-a“ objektové orientace, může porozumět jakékoli struktuře JSON - to je celý bod. Jedná se pouze o směrovaný acyklický graf (DAG) se značkami uzlů (páry klíč / hodnota), který je téměř univerzální datovou strukturou.
Tato jediná požadovaná anotace může být „// Jedná se o značky DAG“. Názvy klíčů mohou být podle potřeby informativní, což umožňuje libovolnou sémantickou arititu.
Jakákoli platforma může analyzovat JSON pouze s několika řádky kódu. XML vyžaduje složité OO knihovny, které nejsou životaschopné na mnoha platformách.
Díky anotacím bude JSON méně interoperabilní. Prostě není co přidat, pokud to, co opravdu potřebujete, je značkovací jazyk (XML) a je jedno, jestli jsou vaše trvalá data snadno analyzována.
ALE jako tvůrce JSON také poznamenal, vždy existovala podpora JS potrubí pro komentáře:
Pokračujte a vložte všechny komentáře, které se vám líbí.
Poté jej předejte do JSMin, než jej předáte svému analyzátoru JSON. - Douglas Crockford, 2012
|
Pokud váš textový soubor, který je řetězcem JSON, bude přečten nějakým programem, jak obtížné by bylo před jeho použitím odstranit poznámky ve stylu C nebo C ++?
Odpověď: Byla by to jedna vložka. Pokud to uděláte, pak lze soubory JSON použít jako konfigurační soubory.
|
Pokud používáte knihovnu Newtonsoft.Json s ASP.NET ke čtení / deserializaci, můžete použít komentáře v obsahu JSON:
// "name": "string"
// "id": int
nebo
/ * Toto je
příklad komentáře * /
PS: Jednořádkové komentáře jsou podporovány pouze u 6+ verzí Newtonsoft Json.
Dodatečná poznámka pro lidi, kteří nemohou myslet z krabice: Používám formát JSON pro základní nastavení ve webové aplikaci ASP.NET, kterou jsem vytvořil. Přečetl jsem soubor, převedl jej do objektu nastavení pomocí knihovny Newtonsoft a v případě potřeby jej použil.
Dávám přednost psaní komentářů o každém jednotlivém nastavení v samotném souboru JSON a opravdu se nestarám o integritu formátu JSON, pokud je knihovna, kterou používám, v pořádku.
Myslím, že se jedná o „snadnější použití / pochopení“, než vytvoření samostatného souboru „settings.README“ a vysvětlení nastavení v něm.
Pokud máte problém s tímto druhem použití; promiň, džin je mimo lampu. Lidé by našli jiné využití proFormát JSON a nelze s tím nic dělat.
|
Myšlenkou JSON je poskytnout jednoduchou výměnu dat mezi aplikacemi. Obvykle jsou webové a jazykem je JavaScript.
Opravdu to neumožňuje komentáře jako takové, ale předání komentáře jako jednoho z dvojic název / hodnota v datech by určitě fungovalo, ačkoli tato data by samozřejmě musela být ignorována nebo zpracována konkrétně kódem pro analýzu.
Vše, co bylo řečeno, není záměrem, aby soubor JSON měl obsahovat komentáře v tradičním smyslu. Měla by to být jen data.
Podívejte se na web JSON pro více podrobností.
|
JSON nepodporuje komentáře nativně, ale můžete si vytvořit svůj vlastní dekodér nebo alespoň preprocesor, který komentáře zbaví, to je naprosto v pořádku (pokud pouze ignorujete komentáře a nepoužíváte je k vedení, jak má vaše aplikace zpracovávat data JSON ).
JSON nemá komentáře. Kodér JSON NESMÍ vydávat komentáře.
Dekodér JSON MŮŽE přijímat a ignorovat komentáře.
Komentáře by nikdy neměly být použity k přenosu něčeho smysluplného. To je
k čemu JSON slouží.
Srov.: Douglas Crockford, autor JSON spec.
|
Právě jsem se s tím setkal u konfiguračních souborů. Nechci používat formát XML (podrobný, grafický, ošklivý, těžko čitelný) nebo formát „ini“ (žádná hierarchie, žádný skutečný standard atd.) Ani formát Java „Vlastnosti“ (například .ini).
JSON může dělat vše, co může, ale je mnohem méně upovídaný a čitelnější pro člověka - a analyzátory jsou v mnoha jazycích snadné a všudypřítomné. Je to jen strom dat. Ale mimopásmové komentáře jsou často nutností k dokumentaci „výchozích“ konfigurací a podobně. Konfigurace nikdy nemají být „úplnými dokumenty“, ale stromy uložených dat, která mohou být v případě potřeby čitelná pro člověka.
Myslím, že pro „platný“ JSON lze použít „#“: „komentář“.
|
Záleží na vaší knihovně JSON. Json.NET podporuje komentáře ve stylu JavaScriptu, / * commment * /.
Podívejte se na další otázku Přetečení zásobníku.
|
JSON má velký smysl pro konfigurační soubory a další místní použití, protože je všudypřítomný a protože je mnohem jednodušší než XML.
Pokud mají lidé silné důvody, aby při komunikaci s daty (ať už platnými nebo ne) neměli komentáře v JSONu, pak by JSON mohl být rozdělen na dva:
JSON-COM: JSON na drátu nebo pravidla, která platí při komunikaci dat JSON.
JSON-DOC: dokument JSON nebo JSON v souborech nebo místně. Pravidla, která definují platný dokument JSON.
JSON-DOC umožní komentáře a mohou existovat další drobné rozdíly, jako je manipulace s mezerami. Analyzátory mohou snadno převádět z jedné specifikace na druhou.
S ohledem na poznámku Douglase Crockforda k této problematice (odkaz @Artur Czajka)
Předpokládejme, že používáte JSON k uchování konfiguračních souborů, které byste chtěli anotovat. Pokračujte a vložte všechny komentáře, které se vám líbí. Poté jej předejte do JSMin, než jej předáte svému analyzátoru JSON.
Mluvíme o obecném problému s konfiguračním souborem (křížový jazyk / platforma) a odpovídá specifickým nástrojem JS!
Zajistěte, aby minify specifické pro JSON mohly být implementovány v jakémkoli jazyce,
ale standardizujte to, aby se to stalo všudypřítomným napříč analyzátory ve všech jazycích a platformách, aby lidé přestali ztrácet čas nedostatkem této funkce, protože pro to mají dobré případy použití, hledají problém na online fórech a přimějí lidi, aby jim říkali, že je to špatný nápad nebo navrhování, že je snadné implementovat odstraňování komentářů z textových souborů.
Druhým problémem je interoperabilita. Předpokládejme, že máte knihovnu nebo API nebo jakýkoli druh subsystému, který má k sobě přidružené některé konfigurační nebo datové soubory. A tento subsystém je
pro přístup z různých jazyků. Pak řeknete lidem: mimochodem
nezapomeňte odstranit komentáře ze souborů JSON, než je předáte analyzátoru!
|
Pokud používáte JSON5, můžete přidat komentáře.
JSON5 je navrhované rozšíření JSON, jehož cílem je usnadnit lidem ruční psaní a údržbu. Dělá to přidáním některých minimálních funkcí syntaxe přímo z ECMAScript 5.
|
Sada nástrojů Dojo Toolkit JavaScript (alespoň od verze 1.4) umožňuje zahrnout komentáře do vašeho JSON. Komentáře mohou být ve formátu / * * /. Sada nástrojů Dojo spotřebovává JSON prostřednictvím volání dojo.xhrGet ().
Podobně mohou fungovat i další sady nástrojů JavaScriptu.
To může být užitečné při experimentování s alternativními datovými strukturami (nebo dokonce seznamy dat) před výběrem poslední možnosti.
|
JSON není orámovaný protokol. Jedná se o bezplatný jazyk. Formát komentáře tedy není pro JSON definován.
Jak již mnoho lidí navrhlo, existuje několik triků, například duplicitní klíče nebo konkrétní klíč _comment, které můžete použít. Je to na tobě.
|
Můžete mít komentáře v JSONP, ale ne v čistém JSON. Právě jsem strávil hodinu pokusem, aby můj program fungoval s tímto příkladem z Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Pokud kliknete na odkaz, uvidíte
? (/ * AAPLhistorická data OHLC z Google Finance API * /
[
/ * Květen 2006 * /
[1147651200000,67,79],
[1147737600000,64,98],
...
[1368057600000,456,77],
[1368144000000 452,97]
]);
Vzhledem k tomu, že jsem měl podobný soubor ve své místní složce, nebyly žádné problémy s politikou stejného původu, takže jsem se rozhodl použít čistý JSON ... a samozřejmě $ .getJSON kvůli komentářům tiše selhával.
Nakonec jsem na výše uvedenou adresu poslal ruční požadavek HTTP a uvědomil jsem si, že typ obsahu byl text / javascript, protože JSONP vrací čistý JavaScript. V tomto případě jsou komentáře povoleny. Ale moje aplikace vrátila obsah / typ aplikace / json, takže jsem musel odstranit komentáře.
|
Toto je otázka „můžete“. A tady je odpověď „ano“.
Ne, neměli byste používat duplicitní členy objektu k plnění dat postranního kanálu do kódování JSON. (Viz „Názvy v objektu BY MĚLY být jedinečné“ v RFC).
A ano, můžete vložit komentáře kolem JSON, které můžete analyzovat.
Ale pokud chcete způsob vložení a extrakce libovolných dat postranního kanálu do platného JSON, zde je odpověď. Využíváme nejedinečnou reprezentaci dat v kódování JSON. Toto je povoleno * ve druhé části RFC v části „mezery jsou povoleny před nebo po některém ze šesti strukturálních znaků“.
* RFC uvádí pouze „mezery jsou povoleny před nebo po některém ze šesti strukturních znaků“, výslovně nezmiňují řetězce, čísla, „false“, „true“ a „null“. Toto vynechání je ve VŠECH implementacích ignorováno.
Nejprve kanonizujte svůj JSON tak, že jej zredukujete:
$ jsonMin = json_encode (json_decode ($ json));
Potom zakódujte svůj komentář v binárním formátu:
$ hex = rozbalit ('H *', $ komentář);
$ commentBinary = base_convert ($ hex [1], 16, 2);
Pak duste binární soubor:
$ steg = str_replace ('0', '', $ commentBinary);
$ steg = str_replace ('1', "\ t", $ steg);
Tady je váš výstup:
$ jsonWithComment = $ steg. $ jsonMin;
|
Zřeknutí se odpovědnosti: To je hloupé
Ve skutečnosti existuje způsob, jak přidat komentáře a zůstat ve specifikaci (není potřeba žádný další parser). Výsledkem však nebudou čitelné komentáře bez jakéhokoli rozebrání.
Mohli byste zneužít následující:
Před nebo po libovolném tokenu jsou povoleny nevýznamné mezery.
Mezery jsou libovolné sekvence jednoho nebo více následujících kódů
body: tabulka znaků (U + 0009), posuv řádků (U + 000A), přeprava
návrat (U + 000D) a mezera (U + 0020).
Hackovaným způsobem to můžete zneužít k přidání komentáře. Například: začněte a ukončete svůj komentář záložkou. Zakódujte komentář v base3 a použijte ostatní prázdné znaky k jejich reprezentaci. Například.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(ahoj základna tři v ASCII) Ale místo 0 použijte prostor, pro 1 použijte posun řádku a pro 2 použijte návrat vozíku.
To vám ponechá spoustu nečitelných mezer (pokud nevytvoříte IDE plugin pro jeho kódování / dekódování za běhu).
Z pochopitelných důvodů jsem to nikdy ani nezkoušel, a neměli byste ani vy.
|
JSON sám o sobě nepovoluje komentáře. Úvaha je naprosto hloupá, protože k vytváření komentářů můžete použít samotný JSON, což zcela vylučuje uvažování, a načte datový prostor analyzátoru zcela bez dobrého důvodu pro přesně stejný výsledek a potenciální problémy, jako jsou: JSON soubor s komentáři.
Pokud se pokusíte vložit komentáře (například pomocí // nebo / * * / nebo #), některé analyzátory selžou, protože to přísně není
v rámci specifikace JSON. To byste nikdy neměli dělat.
Tady například tam, kde můj systém pro manipulaci s obrázky uložil obrazové notace a některé základní formátované (komentáře) související informace (dole):
{
„Notations“: [
{
"anchorX": 333,
"anchorY": 265,
"areaMode": "Elipsa",
"extendX": 356,
"rozsahY": 294,
"neprůhlednost": 0,5,
"text": "Eliptická oblast nahoře",
"textX": 333,
"textY": 265,
"title": "Zápis 1"
},
{
"anchorX": 87,
"anchorY": 385,
"areaMode": "Rectangle",
"extendX": 109,
"rozsahY": 412,
"neprůhlednost": 0,5,
"text": "Rect area \ non bottom",
"textX": 98,
"textY": 385,
"title": "Zápis 2"
},
{
"anchorX": 69,
"anchorY": 104,
"areaMode": "Polygon",
"extendX": 102,
"rozsahY": 136,
"neprůhlednost": 0,5,
"pointList": [
{
"i": 0,
"x": 83,
"y": 104
},
{
"i": 1,
"x": 69,
"y": 136
},
{
"i": 2,
"x": 102,
"y": 132
},
{
"i": 3,
"x": 83,
"y": 104
}
],
"text": "Jednoduchý mnohoúhelník",
"textX": 85,
"textY": 104,
"title": "Zápis 3"
}
],
"imageXW": 512,
"imageYW": 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "Data zápisu obrázku JSON:",
"c02": "-------------------------",
"c03": "",
"c04": "Tato data obsahují obrazové notace a související oblast",
"c05": "výběrová informace, která poskytuje prostředek pro",
"c06": "galerie obrázků pro zobrazení notací s eliptickým,",
"c07": "obdélníkové, polygonální nebo od ruky vyznačené oblasti",
"c08": "přes obrázek zobrazený návštěvníkovi galerie.",
"c09": "",
"c10": "Pozice X a Y jsou v obrazeprostor. Obrázek",
"c11": "rozlišení se udává jako imageXW a imageYW, které",
"c12": "použijete k zvětšení rozsahu notačních oblastí",
"c13": "umístění a velikosti pro zobrazení obrázku,",
"c14": "bez ohledu na měřítko.",
"c15": "",
"c16": "U elips je kotva středem elipsy,",
"c17": "a rozsahy jsou poloměry X a Y.",
"c18": "",
"c19": "U obdélníků je kotva vlevo nahoře a",
"c20": "rozsahy jsou vpravo dole.",
"c21": "",
"c22": "V režimech Freehand a Polygon area the pointList",
"c23": "obsahuje řadu očíslovaných XY bodů. Pokud oblast",
"c24": "je uzavřeno, poslední bod bude stejný jako",
"c25": "první, takže vše, čeho se musíte zabývat, je kreslení",
"c26": "čáry mezi body v seznamu. Kotva a rozsah",
"c27": "jsou nastaveny vlevo nahoře a vpravo dole na vyznačeném",
"c28": "oblast a lze ji použít jako zjednodušující obdélníkový",
"c29": "zjistit polohu kurzoru myši nad těmito typy",
"c30": "oblastí.",
"c31": "",
"c32": "Pozice textx a texty poskytují základní umístění",
"c33": "informace, které vám pomohou najít textové informace",
"c34": "na přiměřeném místě spojeném s oblastí",
"c35": "indikace.",
"c36": "",
"c37": "Neprůhlednost je hodnota mezi 0 a 1, kde 0,5 představuje",
"c38": "50% neprůhledné pozadí a 1.0 představuje zcela neprůhledné",
"c39": "pozadí. Doporučení je, aby byly regiony vykresleny",
"c40": "pouze v případě, že uživatel umístí ukazatel nad obrázek,",
"c41": "a aby byl nakreslen text přidružený k regionům",
"c42": "pouze v případě, že uživatel umístí ukazatel nad označené",
"c43": "region."
}
}
|
Pro náš projekt používáme komentáře strip-json. Podporuje něco jako:
/ *
* Popis
* /
{
// duhy
"unicorn": / * ❤ * / "dort"
}
Jednoduše npm install --save strip-json-comments k instalaci a použití jako:
var strip_json_comments = require ('strip-json-comments')
var json = '{/ * duhy * / "jednorožec": "dort"}';
JSON.parse (strip_json_comments (json));
// => {unicorn: 'cake'}
|
V mém případě musím použít poznámky pro účely ladění těsně před výstupem struktury JSON. Takže jsem se rozhodl použít ladicí informace v hlavičce HTTP, aby nedošlo k rozbití klienta:
header ("My-Json-Comment: Yes, I know it's a workaround ;-)");
|
Chcete-li rozříznout položku JSON na části, přidám řádky „fiktivní komentář“:
{
"#############################" : "Část 1",
"data1": "value1",
"data2": "value2",
"#############################" : "Část 2",
"data4": "value3",
"data3": "value4"
}
|
1
2
další
Vysoce aktivní otázka. Získejte 10 reputace, abyste mohli odpovědět na tuto otázku. Požadavek na reputaci pomáhá chránit tuto otázku před spamem a neodpovědností.
Toto není odpověď, kterou hledáte? Projděte si další otázky označené komentáři json nebo položte vlastní otázku.